W-21354759: Implement SF Payments support in create app package by amittapalli · Pull Request #3698 · SalesforceCommerceCloud/pwa-kit

amittapalli · 2026-03-02T16:04:32Z

Multiple issues have been addressed with this PR. Please see the details in the description below

Description

useAddressFields.jsx — internationalized stateCode/postalCode fields
Without this change (original code), if a customer adds {value: 'DE', label: 'Germany'} to SHIPPING_COUNTRY_CODES:
stateCode field: type is always 'select', options is always countryCode === 'CA' ? provinceOptions : stateOptions. So Germany gets a dropdown with US states (Alabama, Alaska...). So, its already broken!
stateCode required: Always required. So a German customer is forced to pick a US state. Completely wrong.
postalCode label: Says "Zip Code" for everything except CA. Minor but incorrect.
I feel the entire address form is wrong and needs rework but we don't have time for that. So I am trying to introduce the least invasive risk. Existing customers (US or Canada) will not see any difference but other international customers will see a textbox for state/province instead of a hard-coded US dropdown.

hooks/use-sf-payments-country.js -- dynamic country for payment request
We need to determine the country based on the site locale, else it will always default to US

use-sf-payments.js — useSFPaymentsEnabled now checks both local config and API
Currently we only support the value in the API BUT this can break existing customers who might have already modified some of the customers. They can end up with a mix/match of with and without SF Payments. So, with this change, sf payments will always be enabled anyway. But customers have a kill switch to disable it if needed.

checkout/index.jsx — added missing await on doCreateOrder()

Handlebars (bootstrap and templates default.js.hbs) — need to change enabled: false to enabled: true for SF Payments
These handlebar changes are required so that customers who generate PWA based on our template will get the changes we added to SSR.js and default.js

Everything else (SLAS public/private, client IDs, _app-config changes) -- reverted back to public client instead of private client since PWA will be public by default in this release. SF Payments works in public client.

Note: There will be a more cleanup tasks in a subsequent PR

Types of Changes

Bug fix (non-breaking change that fixes an issue)
New feature (non-breaking change that adds functionality)
Documentation update
Breaking change (could cause existing functionality to not work as expected)
Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

Removing a public function or component or prop

Adding a required argument to a function

Changing the data type of a function parameter or return value

Adding a new peer dependency to package.json

Changes

(change1)

How to Test-Drive This PR

(step1)

Checklists

General

Changes are covered by test cases
CHANGELOG.md updated with a short description of changes (not required for documentation updates)

Accessibility Compliance

You must check off all items in one of the follow two lists:

There are no changes to UI

or...

Changes were tested with a Screen Reader (iOS VoiceOver or Android Talkback) and had no issues
Changes comply with WCAG 2.0 guidelines levels A and AA
Changes to common UI patterns and interactions comply with WAI-ARIA best practices

Localization

Changes include a UI text update in the Retail React App (which requires translation)

…ommerceCloud/pwa-kit into amittapalli/pwa-smoke-testing merge changes:

…elds, and revert use current basket hook changes

cc-prodsec · 2026-03-02T16:04:57Z

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

jeffraab-sfdc · 2026-03-02T16:31:49Z

packages/pwa-kit-create-app/assets/bootstrap/js/config/default.js.hbs

+        // Example URLs: sdkUrl: 'https://<instance>.unified.demandware.net/on/demandware.static/Sites-Site/-/-/internal/jscript/sfp/v1/sfp.js'
+        //               metadataUrl: 'https://<instance>.unified.demandware.net/on/demandware.static/Sites-Site/-/-/internal/metadata/v1.json'
+        sfPayments: {
+            enabled: true,


Should our default be true or false? If false then generated sites could be used for demo purposes with placeholder buttons and fake payments. If true then they could only check out if they set up a merchant account and so on for SFP in BM.

So, its a combination of value from this switch and what is coming from shopper config API.
If both true -> feature enabled
If api true but customer decides to switch to false themselves (then its disabled)
If api false but customer kept as true (then still disabled since instance does not allow)
If api false and customer also changed to false (then its obviously disabled)

That way if there are customers that have already customized some of their components, they may not be stuck with a broken experience since they have a kill switch at all times.
We can raise this to Product as well to confirm

Do we even need this flag then? I seem to remember introducing it because we didn't have the shopper config API changes yet.

Helps to keep it since it works as the real kill switch for customers who end up with a mixed mode of behavior. In the past we had this flag but it was never really applied or used. With this PR, I am trying to make use of it. All new customers will have SF Payments enabled regardless. But as I mentioned it allows a customer (especially existing ones) to disable it if they face any unforseen issues when the FT is true

jeffraab-sfdc · 2026-03-02T16:32:24Z

packages/pwa-kit-create-app/assets/bootstrap/js/overrides/app/ssr.js.hbs

+                '*.paypal.com',
+                '*.adyen.com',
+                '*.google.com',
+                '*.demandware.net', // Used to load a valid payment scripts in test environment


Let's leave this demandware.net one out of the generated template.

I can remove it though I noticed that PWA team always had it for the img src in their original code. So
'img-src': [
// Default source for product images - replace with your CDN
'.commercecloud.salesforce.com',
'.demandware.net'
],

jeffraab-sfdc · 2026-03-02T16:33:22Z

packages/pwa-kit-create-app/assets/templates/@salesforce/retail-react-app/app/ssr.js.hbs

+                '*.paypal.com',
+                '*.adyen.com',
+                '*.google.com',
+                '*.demandware.net', // Used to load a valid payment scripts in test environment


Same as above. Any idea why there are two copies of this?

Ah. One is for customers who choose to not extend but get a copy of the template while the other is for customers who don't want the template but extend from the template. So both copies of handle bars are needed

jeffraab-sfdc · 2026-03-02T16:34:08Z

packages/template-retail-react-app/app/components/forms/useAddressFields.jsx

                    countryCode === 'CA'
-                        ? 'Please select your province.' // FYI we won't translate this
-                        : formatMessage({
+                        ? 'Please select your province.'


Should we keep that comment about not translating it?

jeffraab-sfdc · 2026-03-02T16:35:30Z

packages/template-retail-react-app/app/components/sf-payments-express-buttons/index.jsx

        parameters: {
            currency: paymentCurrency,
-            countryCode: paymentCountryCode || fallbackCountryCode || 'US' // TODO: remove US when parameter made optional
+            countryCode: paymentCountryCode || fallbackCountryCode || 'US'


If this parameter is now optional for the payment config API I'd prefer to remove the fallback. There seem to be other PWA hardcoded US and CA values but we don't have to force an optional parameter to have a value.

country code is required apparently and currency is optional. So felt its safer to leave the fallback though with the updated logic, we may never need this fallback but kept it just incase

jeffraab-sfdc · 2026-03-02T16:36:42Z

packages/template-retail-react-app/app/hooks/use-sf-payments.js


 /**
 * Custom hook to check if Salesforce Payments is enabled
+ * //?? true means: if the config is missing, default to "don't block it"


nit: remove the "//" in the comment unless I'm missing something

jeffraab-sfdc · 2026-03-02T16:37:42Z

packages/template-retail-react-app/package.json

    "push": "npm run build && pwa-kit-dev push",
    "save-credentials": "pwa-kit-dev save-credentials",
    "start": "cross-env NODE_ICU_DATA=node_modules/full-icu pwa-kit-dev start",
+    "start:https": "cross-env NODE_TLS_REJECT_UNAUTHORIZED=0 NODE_ICU_DATA=node_modules/full-icu DEV_SERVER_PROTOCOL=https DEV_SERVER_SSL_FILE_PATH=../../localhost.pem pwa-kit-dev start",


Is this temporary?

ah yes. We used it for localhost testing since we can't do https locally with the pwa code. But planning on removing these before the final merge

amittapalli added 5 commits February 23, 2026 18:11

update to latest isomorphic repo

681117c

changes needed to make sf payments work running create-app script

78cc3c9

update bootstrap handlebars as well

bac1d4d

Merge branch 't/team404/sfp-on-pwa' of https://github.com/SalesforceC…

66b0251

…ommerceCloud/pwa-kit into amittapalli/pwa-smoke-testing merge changes:

W-21354759 Fix create app handlebars, country selection in address fi…

e22fe12

…elds, and revert use current basket hook changes

amittapalli requested a review from a team as a code owner March 2, 2026 16:04

W-21354759 address linting

acd79e0

amittapalli requested a review from a team as a code owner March 2, 2026 16:24

jeffraab-sfdc reviewed Mar 2, 2026

View reviewed changes

Minor code review comments

1e3ec54

rasbhat self-requested a review March 2, 2026 19:33

rasbhat approved these changes Mar 2, 2026

View reviewed changes

amittapalli merged commit c48ccf4 into t/team404/sfp-on-pwa Mar 2, 2026
8 of 16 checks passed

amittapalli deleted the amittapalli/pwa-smoke-testing branch March 2, 2026 20:01

Conversation

amittapalli commented Mar 2, 2026

Description

Types of Changes

Changes

How to Test-Drive This PR

Checklists

General

Accessibility Compliance

Localization

Uh oh!

cc-prodsec commented Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Snyk checks have passed. No issues have been found so far.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amittapalli Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amittapalli Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

cc-prodsec commented Mar 2, 2026 •

edited

Loading

amittapalli Mar 2, 2026 •

edited

Loading

amittapalli Mar 2, 2026 •

edited

Loading